home *** CD-ROM | disk | FTP | other *** search
/ IRIX 6.5 Development Libraries / SGI IRIX 6.5 Development Libraries.iso / dist / inst_dev.idb / usr / share / catman / a_man / cat1 / gendist.z / gendist
Text File  |  1998-05-04  |  31KB  |  661 lines
  1.  
  2.  
  3.  
  4. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  5.  
  6.  
  7.  
  8. NNNNAAAAMMMMEEEE
  9.      gendist - generate a software distribution
  10.  
  11. SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
  12.      ggggeeeennnnddddiiiisssstttt [[[[ ----rrrrbbbbaaaasssseeee _r_b_a_s_e ] [ ----rrrrooooooootttt _r_b_a_s_e ] [ ----ssssbbbbaaaasssseeee _s_b_a_s_e ]
  13.           [ ----ssssoooouuuurrrrcccceeee _s_b_a_s_e ] [ ----iiiiddddbbbb _i_d_b_f_i_l_e ] [ ----ssssppppeeeecccc _s_p_e_c_f_i_l_e ]
  14.           [ ----ddddiiiisssstttt _d_i_s_t_d_i_r ] [ ----mmmmrrrr _f_i_l_e ] [ ----ssssaaaa _f_i_l_e ]
  15.           [ ----ccccrrrreeeeaaaattttoooorrrr _n_a_m_e  ] [ ----vvvveeeerrrrbbbboooosssseeee ] [ ----mmmmaaaaiiiinnnntttt ]
  16.           [ ----nnnnooooccccoooommmmpppprrrreeeessssssss ] [ ----nnnnoooossssttttrrrriiiipppp ] [ ----ggggeeeennnniiiiddddbbbb ]
  17.           [ ----ggggeeeennnnssssppppeeeecccc ] [ ----aaaallllllll ] [ _p_a_t_t_e_r_n_s ... ]
  18.  
  19. DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
  20.      _G_e_n_d_i_s_t generates the primary components for software products.  These
  21.      are the product descriptor, the product idb, and the images.  The
  22.      required input is a tree containing all of the files to be shipped, a
  23.      master idb containing a description of each file or directory to be
  24.      included in the product, and a distribution specification (spec) file
  25.      that describes the product structure.
  26.  
  27.      _G_e_n_d_i_s_t reads the distribution specification file and generates products
  28.      as defined in that file.  For each product, the product descriptor file
  29.      is created with the name _p_r_o_d (for example), then the product idb is
  30.      generated with the name _p_r_o_d....iiiiddddbbbb, and then the images with the name
  31.      _p_r_o_d....iiiimmmmaaaaggggeeee for each _i_m_a_g_e defined in the distribution specification file.
  32.  
  33.      Normally, all components of all products defined in the _s_p_e_c_f_i_l_e are
  34.      generated.  The optional _p_a_t_t_e_r_n_s at the end of the command line are
  35.      shell-style patterns that identify particular files to be generated.
  36.      Note that these patterns are matched against the name to be created, not
  37.      against existing files on the disk.  Such patterns should be protected
  38.      from the shell expansion mechanisms.  For example, to generate all of the
  39.      components of the _f_t_n product, use:
  40.  
  41.           gendist ... "ftn*"
  42.  
  43.      Files are created in the _d_i_s_t_d_i_r, which is ``$rbase/usr/dist'' by
  44.      default.
  45.  
  46.      Options:
  47.  
  48.      ----rrrrbbbbaaaasssseeee _r_b_a_s_e
  49.  
  50.      ----rrrrooooooootttt _r_b_a_s_e
  51.                Set the ``root base,'' which is the pathname of the top of the
  52.                destination tree.  The default _r_b_a_s_e is /root, overridden by
  53.                the environment variable rbase.
  54.  
  55.      ----ssssbbbbaaaasssseeee _s_b_a_s_e
  56.  
  57.      ----ssssoooouuuurrrrcccceeee _s_b_a_s_e
  58.                Set the ``source base,'' which is the pathname of the top of
  59.                the source (or build) tree.  The default _s_b_a_s_e is /usr/src,
  60.  
  61.  
  62.  
  63.                                                                         PPPPaaaaggggeeee 1111
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  71.  
  72.  
  73.  
  74.                overridden by the environment variable sbase.
  75.  
  76.      ----iiiiddddbbbb _i_d_b_f_i_l_e
  77.                Set the pathname of the idb.  The default is $rbase/etc/idb,
  78.                overridden by the environment variable idb.  The idbfile must
  79.                be sorted on the 5th and 6th fields.
  80.  
  81.      ----ssssppppeeeecccc _s_p_e_c_f_i_l_e
  82.                Set the pathname of the spec file.  The default is
  83.                $rbase/etc/spec.
  84.  
  85.      ----ddddiiiisssstttt _d_i_s_t_d_i_r
  86.                Create the product components in _d_i_s_t_d_i_r.  The default is
  87.                $rbase/usr/dist, overridden by the environment variable dist.
  88.  
  89.      ----ssssaaaa _s_a_f_i_l_e
  90.                Set the pathname of _s_a_f_i_l_e.  The default is sa.
  91.  
  92.      ----mmmmrrrr _m_r_f_i_l_e
  93.                Set the pathname of the _m_r_f_i_l_e.  The default is mr.
  94.  
  95.      ----ccccrrrreeeeaaaattttoooorrrr _n_a_m_e
  96.                Set the "created by" field in the product to _n_a_m_e.
  97.  
  98.      ----vvvveeeerrrrbbbboooosssseeee  Work verbosely, with more output as the distribution is
  99.                created.
  100.  
  101.      ----nnnnooooccccoooommmmpppprrrreeeessssssss
  102.                Do not compress the images being built.
  103.  
  104.      ----nnnnoooossssttttrrrriiiipppp  Do not strip any of the executables.
  105.  
  106.      ----mmmmaaaaiiiinnnntttt    Generate maintenance product.
  107.  
  108.      ----ggggeeeennnniiiiddddbbbb   Generate an idb from the rbase tree to $rbase/etc/idb.
  109.  
  110.      ----ggggeeeennnnssssppppeeeecccc  Generate a simple spec file to $rbase/etc/spec.
  111.  
  112.      ----aaaallllllll      Generate the product distribution as well as the spec file and
  113.                the idb file.
  114.  
  115.      There is a predefined sequence for building and installing software
  116.      releases, one part of which is to use _g_e_n_d_i_s_t to generate the software
  117.      images.  Before and after using _g_e_n_d_i_s_t, there are other commands to use.
  118.      The simplified sequence of events is:
  119.  
  120.      1. Build the software with ``make install'' and the environment variable
  121.         RAWIDB set.
  122.      2. Sort the idb file with ``sort +4u -6 <$RAWIDB >idb''.
  123.      3. Use _g_e_n_d_i_s_t on idb file (created in step 2) and spec file; output
  124.         includes images.
  125.      4. Use _d_i_s_t_c_p to copy images to other places.
  126.  
  127.  
  128.  
  129.                                                                         PPPPaaaaggggeeee 2222
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  137.  
  138.  
  139.  
  140.      5. Use _i_n_s_t to install the images.
  141.  
  142. DDDDIIIISSSSTTTTRRRRIIIIBBBBUUUUTTTTIIIIOOOONNNN SSSSPPPPEEEECCCCIIIIFFFFIIIICCCCAAAATTTTIIIIOOOONNNN
  143.      The distribution spec file is a text description of the product, image
  144.      and subsystem hierarchy, in the following form:
  145.  
  146.           include file
  147.           define variable value
  148.  
  149.           product pp
  150.               attribute ...
  151.               image ii
  152.                   attribute ...
  153.                   subsystem ss
  154.                       attribute ...
  155.                   endsubsys
  156.               endimage
  157.           endproduct
  158.  
  159.      Products may contain multiple images.  Images may contain multiple
  160.      subsystems.  Attributes apply to the nearest enclosing product, image or
  161.      subsystem (see descriptions below).  When specifying an attribute's
  162.      value(s), use double-quotes to protect whitespace, and single-quotes to
  163.      prevent expansion of ${variables}.
  164.  
  165.      In the attribute descriptions that follow, a ssssuuuubbbbssssyyyysssstttteeeemmmm----rrrraaaannnnggggeeee is a three-
  166.      part product.image.subsystem identifier, followed by a low version number
  167.      and a high version number, all separated by whitespace.  Except within a
  168.      rrrreeeeppppllllaaaacccceeeessss statement (see below) the keyword mmmmaaaaxxxxiiiinnnntttt may be used to indicate
  169.      the highest possible version number.  For example:
  170.  
  171.           x.y.z 1000 2000
  172.           x.y.z 1 maxint
  173.           x.books.eoe 2000 2000
  174.  
  175.      The following attributes may be used.
  176.  
  177.      iiiidddd """"_i_d-_s_t_r_i_n_g""""
  178.           A one-line description or title of the enclosing product, image, or
  179.           subsystem.
  180.  
  181.      vvvveeeerrrrssssiiiioooonnnn _v_e_r_s_i_o_n-_n_u_m_b_e_r
  182.           A version number should be specified at the image level.  All
  183.           subsystems in that image inherit this version number.  Version
  184.           numbers normally increase with each new release of the product, so
  185.           that inst can properly identify upgrade subsystems.
  186.  
  187.      eeeexxxxpppp _e_x_p_r_e_s_s_i_o_n
  188.           This attribute is placed at the subsystem level, and specifies which
  189.           files belong to that subsystem.  All files in the idb having one or
  190.           more group-tags that match _e_x_p_r_e_s_s_i_o_n are included in that subsystem
  191.           when the distribution is created.
  192.  
  193.  
  194.  
  195.                                                                         PPPPaaaaggggeeee 3333
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  203.  
  204.  
  205.  
  206.           The group-tags in the idb are identifiers that categorize the files
  207.           is some convenient way (MAN or DSO for example).  The _e_x_p_r_e_s_s_i_o_n is
  208.           a boolean function written using these tags, and the C logical
  209.           operators ||, &&, ! and ().  For example:
  210.                exp MAN
  211.                exp EOE
  212.                exp "!noship && (EOE || BITMAPS || DSO)"
  213.  
  214.      oooorrrrddddeeeerrrr _o_r_d_e_r-_n_u_m_b_e_r
  215.           This attribute is placed at image level to control the order of
  216.           installations.  Images with lower order numbers are installed before
  217.           images with higher order numbers.
  218.  
  219.      ddddeeeeffffaaaauuuulllltttt
  220.      ddddeeeeffffaaaauuuulllltttt ((((_e_x_p_r_e_s_s_i_o_n))))
  221.           The subsystem is marked for default installation by inst.  If a
  222.           parenthesized _e_x_p_r_e_s_s_i_o_n is given, the subsystem is default only on
  223.           hardware platforms matching that expression.  See HARDWARE
  224.           EXPRESSIONS.
  225.  
  226.      rrrreeeeqqqquuuuiiiirrrreeeedddd
  227.      rrrreeeeqqqquuuuiiiirrrreeeedddd ((((_e_x_p_r_e_s_s_i_o_n))))
  228.           The subsystem is required for installation by inst.  Removal of the
  229.           subsystem is disallowed (upgrade is permitted).  Only subsystems
  230.           containing critical operating system functions should be marked as
  231.           required.  If a parenthesized _e_x_p_r_e_s_s_i_o_n is given, the subsystem is
  232.           default only on hardware platforms matching that expression.  See
  233.           HARDWARE EXPRESSIONS.
  234.  
  235.      mmmmiiiinnnniiiirrrrooooooootttt
  236.      mmmmiiiinnnniiiirrrrooooooootttt ((((_e_x_p_r_e_s_s_i_o_n))))
  237.           A miniroot installation is recommended (not required) or a reboot is
  238.           required to complete the installation.  If a parenthesized
  239.           _e_x_p_r_e_s_s_i_o_n is given, the subsystem is miniroot only on hardware
  240.           platforms matching that expression.  See HARDWARE EXPRESSIONS.
  241.  
  242.      aaaauuuuttttoooommmmiiiinnnniiiirrrrooooooootttt ((((_s_u_b_s_y_s_t_e_m-_r_a_n_g_e))))
  243.           A miniroot installation is required if any subsystem in the
  244.           specified _s_u_b_s_y_s_t_e_m-_r_a_n_g_e is currently installed.  This keyword
  245.           should be used whenever a "live" installation (in multi-user mode)
  246.           causes failures in or harmfully affects other user processes that
  247.           may be executing during the inst session.
  248.  
  249.      mmmmaaaacccchhhh """"_e_x_p_r_e_s_s_i_o_n""""
  250.           Specify that the enclosing product, image or subsystem is suitable
  251.           for installation only on certain hardware platforms matching the
  252.           _e_x_p_r_e_s_s_i_o_n.  Multiple mach expressions for a single product, image
  253.           or subsystem are OR'd.  See HARDWARE EXPRESSIONS.
  254.  
  255.      pppprrrreeeerrrreeeeqqqq ((((_s_u_b_s_y_s_t_e_m-_r_a_n_g_e ...))))
  256.           Installation of the subsystem also requires installation of the
  257.           prerequisite subsystems specified in the ranges.  If a subsystem has
  258.  
  259.  
  260.  
  261.                                                                         PPPPaaaaggggeeee 4444
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  269.  
  270.  
  271.  
  272.           multiple prereq rules, inst permits its installation if any one of
  273.           those rules is satisfied.  In the following example, subsystem s can
  274.           be installed if either:  both p.q.r (any version between 100-200,
  275.           inclusive) and x.y.z (any version greater than 400) are also
  276.           installed; or, a.b.c version 1000 is also installed:
  277.  
  278.           subsystem s
  279.  
  280.               prereq ( p.q.r 100 200
  281.                        x.y.z 400 maxint)
  282.               prereq ( a.b.c 1000 1000 )
  283.  
  284.           endsubsys
  285.  
  286.      rrrreeeeppppllllaaaacccceeeessss _s_u_b_s_y_s_t_e_m-_r_a_n_g_e
  287.      oooobbbbssssoooolllleeeetttteeeessss _s_u_b_s_y_s
  288.           Installation of the subsystem automatically causes the removal of
  289.           subsystems specified by the _r_a_n_g_e.  A subsystem may have multiple
  290.           replaces rules.  It is not necessary to supply a replacement rule
  291.           for other versions of subsystems by the same name (this is enforced
  292.           automatically be inst).
  293.  
  294.           Wildcards (*) are permitted in the subsystem identifier in
  295.           _s_u_b_s_y_s_t_e_m-_r_a_n_g_e.  If the mmmmaaaaxxxxiiiinnnntttt keyword is used as the high version
  296.           number, it will automatically be converted to one less than the
  297.           version number of the containing subsystem.  The shorthand oooobbbbssssoooolllleeeetttteeeessss
  298.           xxxx....yyyy....zzzz is interpreted as rrrreeeeppppllllaaaacccceeeessss xxxx....yyyy....zzzz 0000 mmmmaaaaxxxxiiiinnnntttt.  The following
  299.           rules are equivalent:
  300.  
  301.                image i
  302.                    version N
  303.                    subsystem s
  304.                       replaces x.y.z 0 N-1
  305.                       replaces x.y.z 0 maxint
  306.                       obsoletes x.y.z
  307.                    endsubsys
  308.                endimage
  309.  
  310.           During installation, a subsystem is labeled upgrade (downgrade) if
  311.           it replaces any other currently installed subsystem with a lesser
  312.           (greater) version number, even if the two subsystems have different
  313.           names.
  314.  
  315.           Whenever a subsystem is upgraded or downgraded, its patches are also
  316.           removed.  For this reason, a subsystem X need not declare
  317.           replacement rules for patches that follow subsystems replaced by X.
  318.  
  319.      uuuuppppddddaaaatttteeeessss _s_u_b_s_y_s_t_e_m-_r_a_n_g_e
  320.           The subsystem automatically satisfies all prerequisite rules for any
  321.           subsystem X which has a prereq rule for subsystems specified in the
  322.           _s_u_b_s_y_s_t_e_m-_r_a_n_g_e.  This is useful for honoring the prerequisite rules
  323.           of previously released (hence unchangeable) products, when the
  324.  
  325.  
  326.  
  327.                                                                         PPPPaaaaggggeeee 5555
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  335.  
  336.  
  337.  
  338.           subsystem name is changed in the newer version.  The uuuuppppddddaaaatttteeeessss rule
  339.           does not imply rrrreeeeppppllllaaaacccceeeessss.
  340.  
  341.      ppppaaaattttcccchhhh
  342.           Declare the subsystem to be a patch that replaces files in another
  343.           subsystem.  A patch can also introduce new files.  When a patch is
  344.           installed, any previously installed versions of its files are
  345.           achived under $rbase/var/inst/patchbase.  When a patch is removed,
  346.           the original files are restored.  A patch subsystem must have a
  347.           ffffoooolllllllloooowwwwssss rule.  A patch may replace other patches, but may not
  348.           replace other non-patch subsystems.
  349.  
  350.      ffffoooolllllllloooowwwwssss _s_u_b_s_y_s_t_e_m-_r_a_n_g_e
  351.           Specify that a patch subsystem can only be installed if the base
  352.           subsystem (specified by _s_u_b_s_y_s_t_e_m-_r_a_n_g_e) is also installed.  A patch
  353.           may have multiple follows rules, provided that they all reference
  354.           the same base subsystem.  This allows disjoint version ranges to be
  355.           specified.  A follows rule can only be used within a ppppaaaattttcccchhhh
  356.           subsystem.
  357.  
  358.      ccccuuuuttttppppooooiiiinnnntttt _d_i_r_e_c_t_o_r_y
  359.           This attribute may only be used at the outermost product level (not
  360.           at the image or subsystem level).  It declares _d_i_r_e_c_t_o_r_y to be a
  361.           cutpoint that is owned by the enclosing product, and that it is safe
  362.           for inst to move the entire directory to an alternate drive when
  363.           disk space on the system drive is limited.
  364.  
  365.           When choosing cutpoints, identify the highest-level directories that
  366.           contain only files or sub-directories owned by your product.
  367.           Directories that consume large amounts of disk space are good
  368.           candidates.  Multiple cutpoints are permitted.  For example
  369.  
  370.                product gizmo
  371.                    cutpoint /usr/Gizmo
  372.                    ...
  373.                endproduct
  374.  
  375.           could be used if all files under /usr/Gizmo are owned by the gizmo
  376.           product.  The inst command
  377.  
  378.                Inst> admin relocate gizmo /disk3
  379.  
  380.           will move the contents of /usr/Gizmo to /disk3/usr/Gizmo, and then
  381.           replace /usr/Gizmo with a symbolic link to ../disk3/usr/Gizmo.
  382.  
  383.           It is desirable, but not required, for a product to install all of
  384.           its files underneath cutpoints.  This property simplifies the task
  385.           of sharing software in a network environment using NFS mounts.  For
  386.           example if gizmo installs
  387.  
  388.                /usr/lib/X11/app-defaults/Gizmo
  389.  
  390.  
  391.  
  392.  
  393.                                                                         PPPPaaaaggggeeee 6666
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  401.  
  402.  
  403.  
  404.           then that file will not be moved when /usr/Gizmo is relocated.
  405.  
  406.           Before declaring a cutpoint directory, it is advisable to check for
  407.           self-containment.  Problems may arise with relative symbolic links
  408.           which follow a path up through the cutpoint itself, as in:
  409.  
  410.                    /usr/Gizmo/bin/ls -> ../../../bin/ls
  411.  
  412.           If the directory /usr/Gizmo is moved to a new location at a
  413.           different depth, such as /disk3/usr/Gizmo, then the path
  414.           /usr/Gizmo/bin/ls might no longer be valid.
  415.  
  416. IIIIDDDDBBBB FFFFIIIILLLLEEEE
  417.      The idb contains one line for each file or directory in an entire
  418.      product. The following optional attributes can be specified.
  419.  
  420.      ccccoooonnnnffffiiiigggg(((([update|suggest|noupdate]))))
  421.           Inst gives special treatment to configuration files if a version
  422.           already exists on disk and and either: the file has been altered
  423.           since it was last installed (modified); or the file is not present
  424.           in the installation history (foreign).
  425.  
  426.           During removals, inst does not remove modified config files.  During
  427.           installations, config files are installed normally, except when a
  428.           modified or foreign version already exists on disk.  In that case
  429.           the following variations occur:
  430.  
  431.           ccccoooonnnnffffiiiigggg(_u_p_d_a_t_e) before the file is installed, the modified/foreign
  432.           version is saved as file.O.
  433.  
  434.           ccccoooonnnnffffiiiigggg(_s_u_g_g_e_s_t) the file is installed under the name file.N.  The
  435.           modified/foreign version remains unchanged.
  436.  
  437.           ccccoooonnnnffffiiiigggg(_n_o_u_p_d_a_t_e) no new version of the file is installed.  The
  438.           modified/foreign version remains unchanged.
  439.  
  440.  
  441.      nnnnoooohhhhiiiisssstttt
  442.           After the file is installed, no record of it is kept in the
  443.           installation history.  Useful for scripts which delete themselves
  444.           (for example during a postop), so that showfiles -B does not report
  445.           them as missing.
  446.  
  447.      ddddeeeellllhhhhiiiisssstttt
  448.           The file is completely ignored by inst.  Provided only for backwards
  449.           compatibility.
  450.  
  451.      ddddeeeevvvv((((_m_a_j _m_i_n))))
  452.           Specify the major and minor device numbers.  This attribute is
  453.           required if the file is a block or character special device.
  454.  
  455.  
  456.  
  457.  
  458.  
  459.                                                                         PPPPaaaaggggeeee 7777
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  467.  
  468.  
  469.  
  470.      ssssyyyymmmmvvvvaaaallll((((_v_a_l_u_e))))
  471.           Specifies the link value.  Required when the file is a symbolic
  472.           link.
  473.  
  474.      mmmmaaaacccchhhh(_e_x_p_r)
  475.           Install the file only on hardware platforms matching _e_x_p_r (see
  476.           HARDWARE EXPRESSIONS below).
  477.  
  478.      eeeexxxxiiiittttoooopppp(_c_m_d)
  479.           If the file is installed, execute _c_m_d in a bourne shell, at the end
  480.           of the installation.  Inst sets the following variables in the
  481.           environment for exitops, preops, postops and removeops:
  482.  
  483.           rrrrbbbbaaaasssseeee is set to the root installation directory (see the -r option
  484.           of inst).  Exitops typically conduct all their activity relative to
  485.           $rbase.
  486.  
  487.           ddddiiiisssstttt is set to the location of the software distribution.
  488.  
  489.           iiiinnnnssssttttmmmmooooddddeeee is set to _n_o_r_m_a_l for miniroot installs into /root and live
  490.           installs into /, or _c_l_i_e_n_t for diskless client-tree installations
  491.           using client_inst(1M), or _p_r_o_t_o_t_y_p_e during all other installations.
  492.  
  493.           ddddiiiisssskkkklllleeeessssssss is set to _c_l_i_e_n_t during diskless installations using
  494.           client_inst(1M), or _s_h_a_r_e during diskless installations using
  495.           share_inst(1M), or _n_o_n_e for other, non-diskless installations.
  496.  
  497.           mmmmrrrr is set to _t_r_u_e during miniroot installations, set to _f_a_l_s_e
  498.           otherwise.
  499.  
  500.      pppprrrreeeeoooopppp(_c_m_d)
  501.           Like an exitop, except that Execute _c_m_d just before the file is
  502.           installed.
  503.  
  504.      ppppoooossssttttoooopppp(_c_m_d)
  505.           Execute _c_m_d just after the file is installed.
  506.  
  507.      rrrreeeemmmmoooovvvveeeeoooopppp(_c_m_d)
  508.           Execute _c_m_d if its subsystem is removed.  Removeops are executed at
  509.           the end of an install/remove run, along with any exitops.  Removeops
  510.           are only executed after strict subsystem removals, and not during an
  511.           upgrade.  During an upgrade, any cleanup tasks should be performed
  512.           in the exitop of the upgrade product.
  513.  
  514.      sssshhhhaaaaddddoooowwww
  515.           Causes the file to be installed as file.shd during "live"
  516.           installations when rbase is /.  When the system is shutdown,
  517.           file.shd is renamed to file and only then are its exitops, preops
  518.           and postops executed.  During other installations (for example in
  519.           the miniroot) no special actions are taken.
  520.  
  521.  
  522.  
  523.  
  524.  
  525.                                                                         PPPPaaaaggggeeee 8888
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  533.  
  534.  
  535.  
  536.      nnnnoooossssttttrrrriiiipppp
  537.           Do not invoke strip(1M) on the file, so that its symbol table is
  538.           preserved.
  539.  
  540.      ssssttttrrrriiiippppddddssssoooo
  541.           Invoke strip(1M) on the file using the -f (force) option.  Useful
  542.           for dynamic shared objects.  See the strip(1M) manual page.
  543.  
  544.      nnnnoooorrrrqqqqssss
  545.           Suppress requickstarting for the file after it is installed.
  546.  
  547.      ttttaaaagggg(_v_a_l_u_e)
  548.           At build time, invoke tag(1) with an argument of _v_a_l_u_e on the file.
  549.           value may be a decimal or hex number.  The tag idb keyword is not
  550.           copied to the final idb file since it is of no use at install time.
  551.  
  552. HHHHAAAARRRRDDDDWWWWAAAARRRREEEE EEEEXXXXPPPPRRRREEEESSSSSSSSIIIIOOOONNNNSSSS
  553.      Hardware expressions, or machtags, are boolean expressions evaluated at
  554.      installation time against the current architecture and IRIX version
  555.      number of the system on which the installation occurs, or against the
  556.      machtag values given on the command line when inst -m is used.
  557.  
  558.      Hardware expressions are used in the spec file to restrict installation
  559.      of a subsystem, image or entire product, to specific hardware platforms
  560.      or IRIX releases, and to mark subsystems as default, miniroot, or
  561.      required only for specific platforms.
  562.  
  563.      Hardware expressions in the idb file make it possible to install
  564.      different versions of the same file (including no version at all),
  565.      depending on the target platform.  Each version of the file appears on
  566.      its own idb line.  At most one version of a file can be installed in a
  567.      single subsystem.
  568.  
  569.      When multiple versions of a file are specified, inst installs the one
  570.      whose machtag matches the target platform.  If no matching machtag is
  571.      found, inst installs the version that has no machtag (if specified).
  572.  
  573.      There are two distinct syntaxes for hardware expressions.  The two
  574.      syntaxes may not be intermixed.  In both forms the construct attr=value
  575.      may not be reversed, for example IP22=CPUBOARD does not work.  If the
  576.      leading attr= is omitted, attr is assumed to be CPUBOARD.
  577.  
  578.      The valid attributes are CPUBOARD, CPUARCH, GFXBOARD, SUBGR, VIDEO, MODE,
  579.      TARGOS and DISTOS.  During an inst session the variable TARGOS refers to
  580.      the currently installed IRIX release, as displayed by the command
  581.      "showprods -n eoe*.sw.unix".  DISTOS is the version of eoe*.sw.unix on
  582.      the current software distribution.  These variables will have the value
  583.      -1 if eoe*sw.unix is not present.
  584.  
  585.      FFFFiiiirrrrsssstttt ffffoooorrrrmmmm
  586.           The first form is a whitespace-separated list of attribute/value
  587.           expressions written as:  attr=value attr=value ...
  588.  
  589.  
  590.  
  591.                                                                         PPPPaaaaggggeeee 9999
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598. ggggeeeennnnddddiiiisssstttt((((1111MMMM))))                                                        ggggeeeennnnddddiiiisssstttt((((1111MMMM))))
  599.  
  600.  
  601.  
  602.           An expression evalues to true if there is at least one match for
  603.           every unique attribute referenced in the expression.  For example
  604.           "CPUBOARD=IP22 GFXBOARD=EXPRESS GFXBOARD=NEWPRESS" evalutes to true
  605.           if the cpu is IP22 and the graphics board is either EXPRESS or
  606.           NEWPRESS.
  607.  
  608.      SSSSeeeeccccoooonnnndddd ffffoooorrrrmmmm
  609.           The second form is a C-like syntax in which attr=value pairs can be
  610.           combined with the logical operators &&, ||, and !.  The relational
  611.           operators <, <=, !=, >, > may be used instead of =.  Grouping with
  612.           parentheses is permitted.  Note:  whitespace does not imply logical
  613.           AND as it does in the first form.  If any of the operators except =
  614.           are used, then the entire expression must be written in the second
  615.           form.  The first-form example above could be rewritten as
  616.           "CPUBOARD=IP22 && GFXBOARD=EXPRESS || GFXBOARD=NEWPRESS".
  617.  
  618. SSSSEEEEEEEE AAAALLLLSSSSOOOO
  619.      distcp(1M), inst(1M), install(1), showprods(1M), swpkg(1M), versions(1M).
  620.  
  621.      _S_o_f_t_w_a_r_e _P_a_c_k_a_g_e_r _U_s_e_r'_s _G_u_i_d_e.
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.                                                                        PPPPaaaaggggeeee 11110000
  658.  
  659.  
  660.  
  661.